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SOFTWARE ARCHITECTURE FOR PROVIDING 
LOW LEVEL HARDWARE DEVICE DRIVERS FROM 
THE USER MODE UNDER MULTI-TASKING OPERATING SYSTEMS 

5 BACKGROUND OF THE INVENTION 

1. The Field of the Invention 

This invention relates to hardware device drivers used in an operating system. 
, More particularly, this invention relates to hardware device drivers operating from the 
user mode in an operating system. 
10 2. Present State of the Art 

Very early modem architectures placed a communication modem external to the 
personal computer. Such an external placement relied upon the computer's interface port 
such as a COM port of the personal computer to interface with the modem through which 
data information could be exchanged. The external modem contained all of the 
15 functionality necessary for performing traditional modem functions such as providing 

modulation and demodulation functionality for transmitted data as well as performing 
CODEC functionality required by the telephone network to which the modem was 
connected. 

As technology advanced, both the personal computer and the modem functionality 
20 became more integrated. Such an integration enabled the modem functionality to be 

implemented on a computer card for physical placement within the personal computer. 
That is to say, the functionality once implemented in an external module was integrated 
onto a computer card or circuit board including the modulation functionality as well as 
the CODEC functionality. As the personal computer increased in both capability and 
25 performance, substantial functionality once performed in an external modem or in an 

integrated circuit board modem was able to be integrated into the personal computer. 
Such functionality primarily took the form of software functionality such as the ability 
to handle AT commands, and protocols (i.e., V.42). Such an implementation is 
commonly known in the industry as a WINmodem implementation wherein the 
30 supervisor portion is performed on the personal computer. In such an architecture, the 

modulation device, typically a digital signal processor (DSP), performs the data COM 
functions while the rest of the supervisor portion is implemented on the personal 
computer or host and is implemented in a Windows application. 

In modern traditional operating systems, functionality is partitioned into different 
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privilege levels. One such partitioning configuration employs a user mode and a 
supervisor mode for implementing the privilege partitioning structure. For operating 
systems utilizing popular x86 processors, the utilization of the x86 architecture to 
facilitate the privilege partitioning takes advantage of the x86 utilization of various 
5 privilege modes commonly known as rings. X86 architectures employ a four ring 

partitioning of which most operating systems utilize only two of the rings. Generally, 
ring 0 is utilized for implementing the supervisor mode of the operating system while a 
ring 3 privilege level is employed for implementing a user mode. 

Traditional WINmodem architectures have been implemented consistent with 

1 0 design directives from operating system implementors in that WINmodem designers have 

complied with the generation and placement of hardware device drivers in a ring 0 
environment wherein the supervisor mode is implemented. That is to say, software 
modules such as device drivers placed in the ring 0, or supervisor mode area of the 
operating system literally become part of the operating system. Such an incorporation 

15 simply extends the operating system to do something in addition to the original 

functionality. When large blocks of code, such as device drivers, are integrated into 
ring 0 or the supervisor mode area of the operating system, the opportunities for the 
operating system to become unstable and even seize or ''crash" due to the integration of 
such foreign code into the highly tested kernel mode portion of the operating system 

20 greatly increases. Therefore, in such a WINmodem configuration or other like 

configuration the hardware device driver is integrated into the supervisor mode and 
becomes a supervisor mode driver with only minor functionality such as a CODEC 
implemented on an external card or integrated onto the mother board. 

In a traditional WINmodem or host-based modem implementation, the 

25 functionality of the hierarchy as depicted in Figure 1 was employed. In the architecture, 

a traditional communication application 10 {e.g., HyperTerminal, QuickLink, ProCom, 
NetScape) operating in a user mode communicates in the operating system, using a 
COMM API 12 to transition from a ring 3 privilege level to a ring 0 privilege level 
through a VCOMM virtual communication driver 14 in a Microsoft operating system. 

30 A device driver such as Winmodem VxD device driver 16 resident within a 

supervisor mode interfaces to a virtual device driver such as VCOMM 14 and hardware 
such as hardware 1 8 which may take the form of a modem or other communication-type 
device and may further include video type devices. 

In such an architecture, much of the functionality that was original on the external 
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board or module is now incorporated into a ring 0 or supervisor mode portion of the 
operating system. Such functionality in the case of a modem includes functions such as 
the data pump and optionally includes modulation functionality. Because of the 
substantial nature of these software components, the size of the supervisor mode portion 
5 of the operating system becomes extremely augmented by the inclusion of such code 

within the kernel. Because of the substantial nature of the code included within the 
kernel and the generally less-thoroughly tested nature of third-party or aftermarket device 
drivers, an operating system generally becomes more unstable and susceptible to 
crashing. Furthermore, since such code is located within the supervisor mode or ring 0 
1 0 portion of the architecture, a crash or misbehavior of such code nearly always leads to the 

complete termination of the present operating session. Conversely, applications operating 
in the user mode that display deleterious behavior, are terminated by the supervisor mode 
portion of the operating system when such behavior renders the user mode application 
inoperable. 

15 Additionally, when software vendors generate portions of the software for 

inclusion within the kernel mode, there are additional and even onerous design 
requirements placed upon the software vendor. Such guidelines often inflict limitations 
on what a supervisor mode component of software may perform. Furthermore, such 
restrictive guidelines also render supervisor mode software very difficult to maintain due 

20 to the restriction and limitations of the functionality that may be performed. One 

exemplary limitation for performing such functionality in the kernel mode, is inherent in 
the architecture of x86 processors. For example, supervisor mode code utilizing features 
of the x86 architecture such as the floating point processor or the MMX processor are not 
fully reconstructed when context switching occurs. In an operating system switching 

25 between user and supervisor modes, the context or register values and other information 

such as stack pointers are preserved during a switch, thus enabling a process to resume 
a specific execution thread by reinstalling the register and other flag values when 
returning to the process. However, in the x86 architecture the floating point values and 
the MMX values are not preserved as part of a typical context switch task. Therefore, 

30 supervisor mode components utilizing these features become volatile when values in the 

floating point unit and MMX process are not preserved. While many supervisor mode 
components require sophisticated processing such as that capable of being performed by 
a floating point processor, instability of the operating system is extremely common. 

Thus, it appears that there exists no present technique for providing low level 

35 hardware device drivers from the user mode of an operating system. Furthermore, there 
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does not currently exist techniques for enhancing the reliability of an operating system 
by placing low level device drivers in the user mode portion of an operating system to 
preclude or minimize the vulnerability of the operating system to ill- behaved software 
components. Therefore, a need exists for providing a method and apparatus for placing 
5 low level device drivers in the user mode portion of an operating system and facilitating 

direct interaction with the hardware directly therefrom. 

SUMMARY 

Placement of software components such as device drivers in the supervisor mode 
basically extends the operating system thereby providing additional opportunity for the 

1 0 operating system to fail. In contrast, placement of software components in the user mode 

portion of an operating system protects the kernel functions of the operating system. 
Furthermore, wayward software components in the user mode portion of an operating 
system generally only cause the termination of that particular user application and not the 
crashing of the entire system. 

1 5 The present invention provides an architecture having a thin layer supervisor 

mode driver that appears to a standard user application as a device driver capable of 
servicing hardware directly from the supervisor mode. The present invention further 
comprises a routing driver component coupled to the thin layer device driver to 
communication with a device driver wrapper that provides a "supervisor mode-like" 

20 environment for a device driver. Because of the capabilities of the device driver wrapper, 

device drivers may be extracted from their supervisor mode linkage and relinked to the 
device driver wrapper without requiring recoding as is customary when porting software 
modules. Furthermore, a device driver may be reused between platforms once a device 
driver wrapper exists for each platform with the reusability of a device driver across 

25 multiple platforms being capable of being extended to a family of standard products that 

are interchangeable across platforms. 

These features of the present invention will become more fully apparent from the 
following description and appended claims, or may be learned by the practice of the 
invention as set forth hereinafter. 

30 BRIEF DESCRIPTION OF THE DRAWINGS 

In order that the manner in which the above-recited and other advantages of the 
invention are obtained, a more particular description of the invention briefly described 
above will be rendered by reference to specific embodiments thereof which are illustrated 
in the appended drawings. Understanding that these drawings depict only typical 

35 embodiments of the invention and are not therefore to be considered to be limiting of its 
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scope, the invention will be described and explained with additional specificity and detail 
through the use of the accompanying drawings in which: 

Figure 1 is a simplified architectural diagram of traditional communication 
modules and their operational locations, in accordance with prior art implementations; 
5 Figure 2 is a simplified architectural diagram of the components and relationships 

for providing low level hardware drivers from the user mode, in accordance with the 
preferred embodiment of the present invention; 

Figure 3 is a more detailed description of the functional interfaces between the 
various components for facilitating the relocation of a device driver to the user mode of 
10 an operating system, in accordance with the preferred embodiment of the present 

invention; 

Figure 4 is a simplified depiction of functionality incorporated within the user 
mode to facilitate the placement of a device driver in the user mode of a partitioned 
operating system, in accordance with the preferred embodiment of the present invention; 
1 5 Figure 5 is a simplified diagram of supervisor mode support drivers employed to 

facilitate the operation of a device driver in user mode, in accordance with the preferred 
embodiment of the present invention; 

Figure 6 is a simplified block diagram of the components and relationships for 
providing low level hardware drivers from the user mode in a Windows NT, in 
20 accordance with an alternate embodiment of the present invention; 

Figure 7 is a simplified depiction of functionality incorporated within the user 
mode to facilitate the placement of a device driver in the user mode of a Windows NT 
operating system, in accordance with an alternate embodiment of the present invention; 
and 

25 Figure 8 is a simplified diagram of supervisor mode support drivers employed to 

facilitate the operation of a device driver in user mode in an embodiment employing a 
Windows NT operating system, in accordance with the preferred embodiment of the 
present invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

30 The present invention embodies within its scope both methods and an apparatus 

for enabling a user mode device driver to interact directly with an I/O port or hardware 
device without requiring the direct services of the supervisor mode. The present 
invention also provides a method and apparatus for placing traditional supervisor mode 
drivers in the user mode portion of the operating system thereby enabling the operating 

35 system to terminate a wayward user mode device driver without causing the entire 
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operating system to seize with a supervisor mode device driver exhibits aberrant 
behavior. 

Figure 2 is a simplified block diagram of the architecture employing a thin 
supervisor mode system interface to portray to the operating system a compatible 
5 interface while routing commands and data to a device driver located in the user mode 

for executing and interacting directly with an I/O port or hardware without intermediary 
involvement by the supervisor mode. The present invention allows the operating system 
to see the system interface connections that are expected in the supervisor mode, while 
performing only minimal work in supervisor mode and placing the majority of 

10 functionality in the user mode where they are far less likely to cause catastrophic 

volatility to the operating system when problems occur in a device driver. 

Actual testing of the present architecture has yielded test results showing that for 
a typical modem exchange between a communication application and a corresponding 
hardware device, execution of the transfer was performed at over a 95/5 duty cycle with 

1 5 the substantial majority of the time being consumed by execution in the user mode. The 

architecture of the present invention appears to the user and the user application such as 
a commercial-off-the-shelf communication application that the majority of the work is 
being traditionally performed by a device driver in supervisor mode when in fact the vast 
majority of the work is being performed in the user mode. 

20 Typical operating systems generally operate in two different privilege modes, a 

first privilege mode such as user mode 26 and a second privilege mode such as supervisor 
mode 28. All user applications execute and operate in user mode 26. Typically, user 
mode applications include E-mail, word processing, and graphical programs such as 
games. In a typical architecture, the user mode cannot communicate directly with an I/O 

25 port or hardware. The user mode traditionally is restricted in the functions and processes 

that it can request the system to perform. For instance, one user application is prevented 
from interacting or interfering with the operation of another user application. The 
operating system in user mode attempts to keep each user application isolated to prevent 
them from being improperly behaved and incurring a negative impact on other user 

30 applications. 

Supervisor mode 28 is the portion of the architecture where the operating system 
kernal resides. The incorporation of supervisor mode software modules such as device 
drivers extends the operating system, thus enabling it to perform additional specific 
functions. Typical supervisor mode functionality specifically includes interacting with 

35 I/O ports and hardware (e.g., video display, hard drive, CD ROM drive and floppy drive). 
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In supervisor mode 28, software modules can see all memory, I/O, interrupts and has 
access to all other components. Normally, user mode 26 has no such exposure or control. 

A user application 30 generally operates in user mode 26, however, user 
application 30 needs the services that the operating system provides in the supervisor 
5 mode, and therefore, execution of user application 30 must cross between user mode 26 

and supervisor mode 28 to obtain some of those services. In fact, user application 30 
really can't perform rudimentary functionality such as obtaining a file off of the disk or 
storing information to a disk without the services of supervisor mode 28. 

User application 30 and a system interface driver 34 communicate using 

1 0 Application Programming Interfaces (APIs) 32, a portion of which have been defined in 

the present invention and a standard set used by the operating system. APIs 32 provide 
fundamental command interface capable of passing the appropriate information and 
getting the operating system or the driver which is an extension of the operating system 
in supervisor mode 28 to take that action. For instance, user application 30 may request 

1 5 to open a file named ABC.PPT, which is essentially performed by putting in a command 

with the data that is affiliated with that command followed by the issuance of the specific 
API. The specific API is comprised of a certain number of predefined parameters that 
it needs. Therefore, if a block of data is targeted for storage, then one of the parameters 
for that API is a pointer to the data. 

20 In a traditional architecture implementation, a device driver would reside in the 

supervisor mode, either a standard device driver or a custom device driver for a specific 
type of I/O port or hardware and carries out the specific data processing and appropriate 
control of the hardware as necessary. In the present invention, instead of a traditional 
device driver residing in supervisor mode 28, the supervisor portion, system interface 

25 driver 34 and device router driver 44, are much thinner and leaner with the majority of 

the functionality located in the user mode portion of the invention. The supervisor mode 
portion basically presents the minimal interface entry points that the particular function 
requires by the operating systems. Basic operating system functionality and compatibility 
dictate the a particular kind of device must present a certain interface to the operating 

30 system defining the specifics for interacting with the operating system. 

In one implementation of the present invention utilizing a Microsoft® operating 
system, there is actually a layer provided by the operating system that exists between 
system interface driver 34 and user application 30. This layer, when for example, in user 
mode 26 calls into the operating system using a communications API and is responsible 

35 for all the resources in the system. It performs other functions such as (i) checking to 
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verify if a device is in the system to handle a specific type of a request, (ii) which 
component needs to respond in supervisor mode, and (iii) the interface with which the 
operating system needs to interact. Therefore, system interface driver 34 provides a thin 
driver interface to provide the specific set of entry points for the driver that the operating 
5 system requires. None of the device driver functionality is performed in the supervisor 

mode, although the operating system and user application perceive it as being consistent 
with the more traditional supervisor mode location of the device driver. 

In a typical scenario, user application 30 calls in with an API to the operating 
system with a device name (e.g., Coml, Com2) that the operating system recognizes. 

10 User application 30 calls through API 32 which in turn determines that, for example, 

Coml corresponds with system interface driver 34. System interface driver 34 is further 
comprised of at least one base class 36 which defines a unique requirement for how- 
interface driver 34 "hooks" to the operating system with the respective entry points for 
use by the operating system when interacting. For example, if a disk driver interface is 

15 to be implemented, base class 36 would be referring to a disk driver base class that 

provides insight and understanding about the functionality the operating system will need 
to employ (i.e., it will need to perform functions such as open driver, driver reads, driver 
writes, driver status, etc.). To facilitate functionality, each kind of device driver will have 
unique types of commands that will be received from the operating system, therefore, 

20 each kind of driver will need a unique base class connection to make the architecture 

function properly. A specific example of base class 36 is implemented in the Microsoft® 
Windows NT 4.0 operating system under the name of a port class and employs 
approximately 21 specific actions that the operating system is going to expect the driver 
to perform for proper interaction (e.g., understanding of data structures, command 

25 structures) and the work that is required out of each one through the architecture to 

actually get the work done. In the preferred embodiment, a generic base class is defined 
as opposed to defining base class 36 as, for example, a SCSI or IDE class. 

In a flow of the present invention, when a call comes from user application 30, 
for example, to open a device, the call comes through API 32 through the operating 

30 system into system interface driver 34. Prior to the call for a specific service, the 

architecture passes through an initialization phase wherein the operating system is 
booting or instantiating itself the first time. In such a process, an operating system 
registry 38 is consulted, for example, to determine how many device drivers are needed 
for a session. Following the read of operating system registry 38, the operating system 

35 instantiates an instance of the necessary interfaces and the links to device router 44 based 
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on that information in operating system registry 38. Therefore, for example, if only one 
device will be supported in a session, the requisite data would be reflected in operating 
system registry 38 and would be read by system interface driver 34 as instantiation was 
underway while identifying the quantity of base classes to create within system interface 
5 driver 34, and the quantity of connections to establish between system interface driver 34 

and device router driver 44. Therefore, in an example where one device will be 
supported, only a single instantiation is performed and if a multiple number of devices 
are to be supported then a multiple number of instantiations will be performed. 

A configuration program 42 is executed as the operating system boots. 

10 Configuration program 42 contains sufficient knowledge about the operating system 

registry 38, the operating system itself and potential hardware or devices or device drivers 
that could be used in the system. Configuration program 42 also contains functionality 
to determine through operating system registry 38 the presence of devices for the session 
or devices that have been recently inserted, which is yet further notified through an 

15 operating system configuration manager 40, when, for example, a PCMCIA card or a 

CardBus card has been inserted during operation. Operating system configuration 
manager 40 recognizes that the new device has been inserted, works with the operating 
system in supervisor mode to determine who is intended to support that device using an 
identification string that identifies each hardware piece in operating system registry 38 

20 once the device is initially installed. When the device is inserted or is found present by 

operating system configuration manager 40, configuration program 42 in user mode 26 
establishes a connection between itself and operating system configuration manager 40. 

When the device is recognized by operating system configuration manager 40, 
operating system configuration manager 40 calls through interface 52 into user mode 26 

25 and notifies configuration program 42 that a device is present. Configuration program 

42 registers as the object that is going to take care of the device and registers itself with 
operating system configuration manager 40 requesting that it be notified if devices are 
inserted. 

Next, configuration program 42 identifies the device, works through operating 
30 system registry 38 to store information regarding the settings to use for the hardware, 

driver or drivers for that session, writes that information into operating system registry 
38 and sends a message 43 to a device driver wrapper 46 to notify the architecture that 
a new device is present requesting support. Device driver wrapper 46 then sends a 
message through interface 56 to go from user mode 26 down to device router driver 44 
35 stating that a new device is present and the location where information about the new 
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device is located in operating system registry 38. Therefore, once configuration 
program 42 has stored the information in operating system registry 38 and sends the 
message to device driver wrapper 46, the functionality of configuration program 42 is 
complete. 

5 Device driver wrapper 46 sends a message to device router driver 44 which then 

instantiates the appropriate handlers 60, 66 and 68 and device router driver 44 then sends 
a message to system interface driver 34 for notification that an additional instantiation is 
needed. Both system interface driver 34 and device router driver 44 read the information 
stored in operating system registry 38 by configuration program 42 and configure 

10 themselves accordingly to allocate system resources such as memory or IO space, 

interrupts and other services that are only feasibly performed by a device driver in 
supervisor mode. Such "supervisor mode-only" services are then set up by system 
interface driver 34. To this point, an instantiation of base class 36 that is configured to 
the parameters that the operating system deduced in conjunction with operating system 

15 configuration manager 40 and configuration program 42 are complete. Next, device 

driver wrapper 46 loads device driver 48 for use by the particular target device such as 
an I/O port or hardware. That is to say, device driver wrapper 46 loads device driver 48 
and then instantiates all the remaining threads that constitute the rest of interface or 
threads 56. 

20 Following the loading of device driver 48 by device driver wrapper 46, device 

driver wrapper 46 makes the connection through threads 56 to device router driver 44 and 
device router driver 44 reads operating system registry 38 and instantiates a link name 62 
which is a unique link name for every device supported and a unique driver name for 
every driver to be supported. For example, this provides a method wherein a port open 

25 command comes in from user application 30 and system interface driver 34 knows 

through operating system registry 38 that COM1 is really COMm calling down from user 
mode 26 into supervisor mode 28 ending up in system interface driver 34 and 
instantiating one of base classes 36 thereby behaving similar to an alias for COM1 . For 
example (see Figure 8), one user application 30 decides to operate as COM3 to system 

30 interface driver 34' but is known as COMSMDevice 0 in one instance. Because of the 

unique name, device router driver 44" from operating system registry 38 knows that in 
this particular case system interface driver 34" is to behave as a regular modem and that 
is, for example, link driver_0 in device router driver 44". Therefore, it knows to send the 
calls through threads 56". 



35 
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Furthermore in the present example (Figure 8), if the user makes a different 
selection in an exemplary user application to select, for example, operation in a cellular 
mode such as originating a GSM call with the same hardware, operating continues 
through COM3, therefore, system interface driver 34" still presents itself as COM3 and 
5 is known in the system as COM3 but now operates with device router driver 44" to link 

to driver l instead of driver_0. Linking to driver l operates through another interface 
of threads 56"' to device driver wrapper for driver l instead of driverJX Therefore, a 
device driver wrapper is present for each device driver and also a set of threads 56 exists 
between device router driver 44" and each device driver wrapper. As far as the operating 

10 system is concerned and the user application is concerned, it appears as if it is still 

COM3. That is to say, internally the system interface driver presents the exact same face 
to the world but the device router driver steers it to and from supervisor mode 28 through 
a different link driver object 60 (Figure2). In summary, link driver objects 60,66 and 68 
can steer routing from one to the other and when device driver O 48 is hooked to link 

1 5 driver 60 which could be a standard modem and device driver_l 72 with its wrapper 70 

at user mode with its set of threads like 56 could be working through link driver 66 and 
be a GSM file and by simply changing the information in the registry through an 
application or an applet, as known by some operating systems, different functionality may 
be created through the same virtual pipe through the system. As far as the user is 

20 concerned, the hardware remains the same, the user application remains the same but 

internally to the architecture of the present invention, it is routed differently to a different 
device driver running in ring 3 to achieve a different result. 

Figure 3 depicts a more detailed look at interfaces between system interface driver 
34, device router driver 44 and device driver wrapper 46 (Figure 2). Thread 54 is a single 

25 thread between system interface driver 34 and device router driver 44. Thread 54 is a 

single thread per device that is being supported. Therefore, if there is one device driver 
or one hardware device or I/O port, then there will be one thread 54. This single thread 
provides a single entry point where a command or a value that directs, for example, an 
interrupt request, an open or a close, a read or a write or a status. Therefore, interface 90 

30 which in one embodiment employs an internal IOCTL command common to Microsoft® 

operating systems is changed depending upon the number of things that need to be 
performed which is influenced by the kind of driver being supported by the architecture. 
Thread 54 is created in the operating system when system interface driver 34 instantiates 
itself. 

3 5 Threads 56 between device router driver 44 and individual device driver wrappers 
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46, 70 and 74 are individual threads: interrupt, device open, device close, device read, 
device write and device get status are all unique threads. Figure 5 is a diagram of a single 
device instance. If there are multiple devices then there would be multiple instances of 
each of these. It should be reiterated that in Figure 3, thread 54 and threads 56 are not 
5 symmetrical. In thread 54, one thread performs all of the functionality depending on 

which function is requested. For example, suppose the user application has requested an 
open command. A thread is created in the operating system between system interface 
driver 34 and device router driver 44. System interface driver 34 calls into the device IO 
control entry point at device router driver 44 with thread 54 which is basically a request 

10 to have the operation performed. Device router driver 44 pends thread 54 and since it is 

the only thread that is between the two devices, no other calls from the operating system 
or user application can come through until that one is completed. 

Device router driver 44 then takes the information from the device IO control call 
and that pended thread 54 and completes device router driver's 44 request via threads 56 

15 DeviceOpen thread for that device to which the command was directed. A simplified 

description suffices to state that the DeviceOpen thread to the device driver, runs in 
device driver wrapper 46 and device driver 48 to perform all the necessary functionality 
to open the device or I/O port. Once the device is opened, device driver wrapper 46 
issues to device router driver 44 on that same device open thread asking it to run that one 

20 again and device router driver 44 pends that thread, that, and we'll talk about the rest of 

that here in a moment. 

When data comes back from the device driver in user mode from the open 
command, the open operation is complete and device router driver 44 pends the new 
thread from the open that was just performed. Since the process is not yet ready to be 

25 repeated, it is not necessary to perform an open yet and the thread is not run. The data 

is then put in the data structure that the operating system specifically wants to see and the 
single thread 54 is completed which then executes the data by moving it up to the user 
application through the original open call through interface 32. 

It should be clarified that thread 54 when it is not performing is complete and 

30 therefore not executing. Also, during initialization, when device driver wrapper 46 first 

instantiates, it links itself to device router driver 44 by establishing all the threads that 
comprise threads 56 and by calling through using the device IO control, for example, 
from user mode 26 to supervisor mode 28 and in the exemplary case of a communication 
(COM) device, 23 individual threads per device get instantiated between device driver 

35 wrapper 46 and device router driver 44. 
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As the initialization process proceeds, each thread is received and pended by 
device router driver 44 which means that once the components of the present invention 
are initialized and the user application is yet to issue requests, thread 54 between system 
interface driver 34 and device router driver 44 is complete and not functioning, while all 
5 of the 23 threads of threads 56 from device router driver 44 in supervisor mode 28 to 

device driver wrapper 46 located in user mode 26 are pended. Pending threads provides 
performance enhancement since if one were to simply call from user mode 26 from an 
application down to supervisor mode 28, a context switch would be required every time, 
which as those skilled in the art appreciate, requires substantial time to perform due to 
1 0 the delay in storing register and pointer values and loading other register and pointer 

values. 

A second problem also occurs in that every time one crosses the boundary 
between user mode and supervisor mode, the operating system takes that opportunity to 
service any pending high priority events. Because device drivers need to operate in 

1 5 substantially real time, the introduction of significant delays introduced between calls 

becomes unacceptable. Therefore, by initiating and pending the individual threads of 
threads 56 performance is greatly enhanced by foregoing context switching. Those 
skilled in the art appreciate the setting of a thread to "complete" starts the thread 
executing again and a mode transition and hence a context switch is not necessary. 

20 Additionally, context switching between modes introduces problems inherent in 

the x86 architecture in that co-processor registers are not preserved. By placing the 
device driver in user mode, the operating system processes the switching, for example in 
multitasking, and therefore forgoes the x86 shortcomings. Furthermore, in the present 
invention, the threads are prioritized relative to the operating system. 

25 Figure 4 depicts the composition of the device driver and the components of the 

device driver wrapper, in accordance with the preferred embodiment of the present 
invention. Prior discussion relating to device driver wrapper 46 have depicted it as a 
monolithic entity when in the preferred embodiment of the present invention, device 
driver wrapper 46 is more incitefully depicted as a composition of functional modules 

30 which greatly enhance the reusability and minimize the quantum of code that must be 

customized between implementations on various hardware and operating system 
platforms. Device driver wrapper 46 may also be viewed as a frame or component that 
facilitates the relocation of a device driver from the supervisor mode to the user mode 
with minimal alterations to the device driver. 
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In Figure 4, the architecture of the present invention is depicted such that the 
device driver originating in a supervisor mode may be relinked with device driver 
wrapper 46 and as far as device driver 48 knows, it is still operating as usual. Component 
86 functions as a driver interface API to user mode API emulation/real time emulation 
5 applications. As device driver 48 is concerned, it perceives itself as operating in 

supervisor mode. What the present invention has done is to put a wrapper around device 
driver 48 and enabled it to continue to operate as it was originally designed. I n 

order to provide such an environment for device driver 48, component 86 provides a real 
time emulation that is created using standard operating system calls and functions to 

10 emulate that environment for device driver 48. Additionally, component 114 provides 

an operating system for user mode API set which is basically the standard operating 
system for user mode APIs. In Figure 4, component 86 is illustrated above component 
1 14 because of the API expanding effect of component 86. Device driver wrapper 46 
provides all of the interfaces required by device driver 48 when operative in the 

1 5 supervisor mode and facilitates the extraction of a device driver previously designed to 

operate in supervisor mode and the subsequent placement of the device driver into the 
user mode by plugging the device driver into the device driver wrapper. 

For example, in one embodiment, device driver wrapper 46 emulates as far as 
device driver 48 is concerned a system interface layer in supervisor mode. Therefore, as 

20 far as device driver 48 is concerned, it has hooked itself just like it does in supervisor 

mode to that system interface layer for its specific functionality. For a COM driver that 
would be VCOMM in a Microsoft operating system. So as far as the device driver is 
concerned, it perceives that it has connected itself to VCOMM when in reality it has 
connected itself to the device driver wrapper. Because of this emulated environment 

25 provided by device driver wrapper 46, device driver 48 may be utilized in its entirety 

without stripping or reworking portions of the device driver. In the preferred 
embodiment of the present invention, component 1 14 is part of the operating system 
while component 86 could alternatively be merged with device driver wrapper 46. 

Figure 5 is a simplified block diagram of the architecture for multiple user 

30 applications interfacing with multiple device drivers. Multiple instances of thread 54 are 

depicted by thread 55 and 61. Likewise, device router driver 44' illustrates multiple 
device driver base classes 60, 66 and 68 while system interface driver 34' illustrates 
multiple driver base classes as well. Figure 5 further illustrates that each device has its 
own interrupt, unique port addresses and separate read and write data cues and threads. 
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Figure 6 depicts a simplified block diagram for implementing the present 
invention in a Microsoft NT® 4.x and WinModem architecture environment using 
functions and terminology consistent therewith. Therefore, instead of being a generic 
user application 30, a COM application would be created using NT specific definitions 
5 such as a port class rather than a base class. Additionally, in Figure 6, the device driver 

is designed to integrate into VCOMM or unimodem. 

Figure 7 is a simplified block diagram of an implementation of the present 
invention within a Microsoft NT 4.0 operating system environment, in accordance with 
the preferred embodiment of the present invention. In Figure 7, a series of modular 

1 0 protocol modules are presented which include functionality such as fax, DTE, v.42, v.80, 

etc. which may be reused across multiple platforms. As described above, the present 
architecture provides a partitioned structure such that reuse is maximized requiring only 
the minimal amount of code to be rewritten when porting or upgrading operating systems. 
Device driver 48* is depicted as being taken from a supervisor role, which while not a 

1 5 requirement, certainly enhances the reusability of legacy drivers. 

Likewise, device driver wrapper 46' provides a Win32 compatible API 
environment for device driver 48'. One of the few portions of the user mode driver 
created by the architecture of the present invention is the hardware specific interfacing 
portion for directly controlling the hardware. In Figure 7, the SDPI DRV represents that 

20 portion of the code that is specific to unique hardware. STPI DRV is an API chosen to 

adopt into a WinModem and soft modem implementations but a LAN driver would not 
have one of those. 

The present invention may be embodied in other specific forms without departing 
from its spirit or essential characteristics. The described embodiments are to be 
25 considered in all respect only as illustrative and not restrictive. The scope of the 

invention is, therefore, indicated by the appended claims rather than by the foregoing 
description. All changes which come within the meaning and range of equivalency of the 
claims are to be embraced within their scope. 

What is claimed is: 
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1 . In an operating system having at least a user mode and a supervisor mode 
for execution of a user application on a computer, a method for driving an Input/Output 
(I/O) port from a device driver operating in said user mode, said method comprising the 
steps of: 

5 a) receiving at a system interface driver operating in said supervisor 

mode an I/O port command from said user application transferred via an 
operating system API and a communication resource of said operating system, 
said system interface driver further providing a compatible interface to said 
communication resource of said operating system; 
10 b) communicating said I/O port command via an internal device IO 

control command between said system interface driver and a device router driver 
also operating in said supervisor mode; 

c) routing said I/O port command to a device driver resident within 
said user mode; 

1 5 d) said device driver resident within said user mode obtaining direct 

privileged access to said supervisor mode of said operating system; and 

e) said device driver resident within said user mode presenting said 
I/O port command as processed within said device driver to said I/O port. 

2. The method for driving an Input/Output (I/O) port from a device driver 
20 operating in said user mode, as recited in claim 1 , further comprising the steps of: 

a) establishing at least one thread between said system interface 
driver and said device router driver for use in said communication step to send 
said internal device IO control command therebetween; and 

b) establishing at least one thread between said device router driver 
25 and said device driver resident within said user mode for use in said routing step 

to send said I/O port command to said device driver. 

3. The method for driving an Input/Output (I/O) port from a device driver 
operating in said user mode, as recited in claim 2, wherein said establishing steps 
comprise the steps of: 

30 a) establishing said at least one thread between said system interface 

driver and said device router driver; 

b) pending said at least one thread between said system interface 
driver and said device router driver; 

c) establishing said at least one thread between said device router 
35 driver and said device driver resident within said user mode; and 
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d) pending said at least one thread between said device router driver 
and said device driver resident within said user mode. 

4. The method for driving an Input/Output (I/O) port from a device driver 
operating in said user mode, as recited in claim 1, wherein said routing said I/O port 

5 command to a device driver resident within said user mode step comprises the steps of: 

a) routing said I/O port command to a device driver wrapper resident 
within said user mode, said device driver wrapper providing an operating system 
API environment of user mode APIs to facilitate relocating said device driver 
from said supervisor mode to said user mode; and 

10 b) said device driver wrapper issuing one of said user mode APIs to 

said device driver corresponding to said I/O port command. 

5. The method for driving an Input/Output (I/O) port from a device driver 
operating in said user mode, as recited in claim 4, wherein operating system API 
environment of said device driver wrapper further comprises a means for emulating a 

1 5 driver interface to user mode API. 

6. The method for driving an Input/Output (I/O) port from a device driver 
operating in said user mode, as recited in claim 5, wherein said obtaining direct privileged 
access to said supervisor mode step comprises the step of issuing one of said operating 
system APIs to request supervisor privileges of said supervisor mode from said device 

20 driver wrapper within said user mode. 

7. In an operating system having at least a user mode and a supervisor mode 
for execution of a user application on a computer, a method for interfacing with an I/O 
port from a device driver operating in said user mode, said method comprising the steps 
of: 

25 a) in a thin-layer supervisor mode system interface driver, presenting 

an interface to a communication resource of said operating system to receive from 
said user application via an operating system API and said communication service 
an I/O port command and wherein said communication service of said operating 
system perceives said system interface driver as comprising a device driver 

30 traditionally resident within said supervisor mode and capable of directly 

interfacing with said I/O port; 

b) routing said I/O port command to said device driver resident 
within said user mode; 

c) said device driver resident within said user mode obtaining direct 
35 privileged access to said supervisor mode of said operating system; and 
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d) said device driver resident within said user mode presenting said 
I/O port command as processed within said device driver to said I/O port. 

8 . The method for interfacing with an I/O port from a device driver operating 
in said user mode, as recited in claim 7, wherein said routing said I/O port command to 

5 said device driver resident within said user mode step comprises the steps of: 

a) receiving at said system interface driver said I/O port command 
from said user application transferred via an operating system API; and 

b) communicating said I/O port command via an internal device IO 
control command between said system interface driver and a device router driver 

1 0 also operating in said supervisor mode. 

9. The method for interfacing with an I/O port from a device driver operating 
in said user mode, as recited in claim 8, further comprising the steps of: 

a) establishing at least one thread between said system interface 
driver and said device router driver for use in said communication step to send 

15 said internal device IO control command therebetween; and 

b) establishing at least one thread between said device router driver 
and said device driver resident within said user mode for use in said routing step 
to send said I/O port command to said device driver. 

10. The method for interfacing with an I/O port from a device driver operating 
20 in said user mode, as recited in claim 9, wherein said establishing steps further comprise 

the steps of: 

a) establishing said at least one thread between said system interface 
driver and said device router driver for use in transferring data between said I/O 
port and said user application; 
25 b) pending said at least one thread between said system interface 

driver and said device router driver; 

c) establishing said at least one thread between said device router 
driver and said device driver resident within said user mode for use in transferring 
data between said I/O port and said user application; and 

30 d) pending said at least one thread between said device router driver 

and said device driver resident within said user mode. 

1 1 . The method for interfacing with an I/O port from a device driver operating 
in said user mode, as recited in claim 7, wherein said routing said I/O port command to 
a device driver resident within said user mode step comprises the steps of: 
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a) routing said I/O port command to a device driver wrapper resident 
within said user mode, said device driver wrapper providing an operating system 
API environment of user mode APIs to facilitate relocating said device driver 
from said supervisor mode to said user mode; and 

5 b) said device driver wrapper issuing one of said user mode APIs to 

said device driver corresponding to said I/O port command. 

12. The method for interfacing with an I/O port from a device driver operating 
in said user mode, as recited in claim 1 1 , wherein operating system API environment of 
said device driver wrapper further comprises a means for emulating a driver interface to 

10 user mode API. 

1 3 . The method for interfacing with an I/O port from a device driver operating 
in said user mode, as recited in claim 12, wherein said obtaining direct privileged access 
to said supervisor mode step comprises the step of issuing one of said operating system 
APIs to request supervisor privileges of said supervisor mode from said device driver 

1 5 wrapper within said user mode. 

14. In an operating system having at least a user mode and a supervisor mode 
for execution of a user application on a computer, a structure to enable said user 
application to interact via a device driver operating in said user mode with an I/O port as 
directed in an I/O port command from said user application, comprising: 

20 a) a system interface driver for operating in supervisor mode, said 

system interface driver having minimal interface entry points required by said 
operating system and further appearing to said operating system as if said device 
driver is resident within said supervisor mode; 

b) a device router driver operably coupled to said system interface 
25 driver and also resident in said supervisor mode to communicate said I/O port 

command between said system interface driver and said device driver and to route 
said I/O port command to said I/O port via said device driver; and 

c) a device driver wrapper resident within said user mode and 
operably coupled to said device router driver to provide an operating system API 

30 environment of user mode APIs to facilitate relocating said device driver from 

said supervisor mode to said user mode, said device driver wrapper further 
capable of emulating a driver interface to user mode API. 

1 5 . The structure to enable said user application to interact via a device driver 
operating in said user mode with an I/O port as directed in an I/O port command from 

35 said user application, as recited in claim 14, wherein said system interface driver further 
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comprises at least one base class to define requirements of said system interface driver 
and how said system interface driver interfaces with said operating system. 

16. A computer-readable medium for driving an Input/Output (I/O) port from 
a device driver operating in a user mode of an operating system having at least said user 
mode and a supervisor mode for execution of a user application on a computer, said 
computer-readable medium having computer-executable instructions for performing steps 
comprising: 

a) receiving at a system interface driver operating in said supervisor 
mode an I/O port command from said user application transferred via an 
operating system API and a communication resource of said operating system, 
said system interface driver further providing a compatible interface to said 
communication resource of said operating system; 

b) communicating said I/O port command via an internal device IO 
control command between said system interface driver and a device router driver 
also operating in said supervisor mode; 

c) routing said I/O port command to a device driver resident within 
said user mode; 

d) said device driver resident within said user mode obtaining direct 
privileged access to said supervisor mode of said operating system; and 

e) said device driver resident within said user mode presenting said 
I/O port command as processed within said device driver to said I/O port. 

17. The computer-readable medium of claim 16, having further computer 
executable instructions for performing the steps of: 

a) establishing at least one thread between said system interface 
driver and said device router driver for use in said communication step to send 
said internal device IO control command therebetween; and 

b) establishing at least one thread between said device router driver 
and said device driver resident within said user mode for use in said routing step 
to send said I/O port command to said device driver. 

18. The computer-readable medium of claim 17, wherein said computer 
executable instructions for performing said establishing steps, comprise computer 
executable instructions for performing the steps of: 

a) establishing said at least one thread between said system interface 
driver and said device router driver; 
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b) pending said at least one thread between said system interface 
driver and said device router driver; 

c) establishing said at least one thread between said device router 
driver and said device driver resident within said user mode; and 

5 d) pending said at least one thread between said device router driver 

and said device driver resident within said user mode. 

19. The computer-readable medium of claim 16, wherein said computer 
executable instructions for performing said routing said I/O port command step comprise 
computer executable instructions for performing the steps of: 

1 0 a) routing said I/O port command to a device driver wrapper resident 

within said user mode, said device driver wrapper providing an operating system 
API environment of user mode APIs to facilitate relocating said device driver 
from said supervisor mode to said user mode; and 

b) said device driver wrapper issuing one of said user mode APIs to 

1 5 said device driver corresponding to said I/O port command. 

20. The computer-readable medium of claim 19, wherein said computer 
executable instructions for said operating system API environment of said device driver 
wrapper further comprises computer executable instructions for implementing a means 
for emulating a driver interface to user mode API. 

20 21. The computer-readable medium of claim 20, wherein said computer 

executable instructions for performing the step of obtaining direct privileged access to 
said supervisor mode comprises computer executable instructions for performing the step 
of issuing one of said operating system APIs to request supervisor privileges of said 
supervisor mode from said device driver wrapper within said user mode. 



25 



WO 99/39254 



PCT/US99/02073 



1 / 8 




CD 



WO 99/39254 



PCT/US99/02073 



2 / 8 




WO 99/39254 



PCT/US99/02073 



3 / 8 



CD 

•-r> 




i 



WO 99/39254 



PCT/US99/02073 




WO 99/39254 



PCT/US99/02073 



5/8 

CO 




WO 99/39254 



PCT/US99/02073 



6 / 8 




WO 99/39254 



PCT/US99/02073 




WO 99/39254 



PCT/US99/02073 



8 / 8 




